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(54) Permit for controlling access to services In protected memory systems 

(57) One embodiment of the present invention pro- 
vides a method and an apparatus for controlling access 
to services in a protected memory system. The method 
makes use of a permit, which includes an access con- 
trol mechanism (500) that resides in a memory space 
that is protected from a user of the permit. The method 
includes receiving a request for a service through a per- 
mit, the permit comprising an object (300) defined within 
an object-oriented programming system. In response to 
the request the method activates an access control 
mechanism within the permit. This access control 
mechanism controls access to the service and resides 
in a memory space that is protected from a user of the 
permit such that the access control mechanism is trig- 
gered by invoking (502) a method (306-310) on the per- 
mit If the access is allowed, the method accesses the 
service by performing an invocation (506) on a control- 
led object (320). This controlled object includes meth- 
ods (324-328) to perform the service, and is otherwise 
protected from the user of the permit. Another variation 
of the above embodiment includes receiving, at a permit 
issuing authority, a request for the permit from an entity 
(such as a person, a computer program or a computer 
process) requiring access to the service. If the request 
includes valid authorisation information, a permit is 
issued (412) to the entity. A further variation of the 
above embodiment includes creating a copy of the per- 
mit and transferring the copy to an entity requiring 
access to the service. 
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Description 
BACKGROUND 

[0001] The present invention relates to protection s 
mechanisms in computer systems. More specifically, 
the present invention relates to a method and an appa- 
ratus for controlling access to services provided by 
other applications in protected memory systems. 
[0002] Programming languages such as the Java™ w 
programming language (developed by SUN Microsys- 
tems. Inc. of Palo Alto. California) and associated sup- 
porting interfaces presently provide a reliable and 
secure infrastructure to support the transfer of an appli- 
cation across a computer network, and to run the appli- 75 
cation on a wide range of computing platforms. 
Because of developments such as Java, it is becoming 
increasingly common to load an application, such as a 
Java applet, from a remote server onto a local machine, 
and to execute the application on the local machine. 20 
[0003] However, present computing systems are not 
designed to allow computer applications from different 
vendors to interact with each other in a controlled way 
so that the applications can work together to accomplish 
a given task One problem in doing so is that application 2s 
vendors typically want to control the way in which these 
interactions take place. For example, it may be useful for 
a tax application to access capital gains information 
from a home brokerage application. However, the home 
brokerage application needs to protect the privacy of so 
the customer's portfolio. Hence, the tax application can- 
not be given unrestricted access portfolio data from the 
home brokerage application. 

[0004] Historically, the task of controlling accesses to 
services in computer systems has been handled 3s 
through hardware mechanisms, such as hardware 
capabilities systems. However, such special-purpose 
hardware is not present on all computing platforms. 
Consequently, it is not practical to use such hardware to 
control access to services for portable applications, 40 
such as a Java™ applet which is designed to operate 
across a wide range of computing platforms. 

SUMMARY 

45 

[0005] One embodiment of the present invention pro- 
vides a method and an apparatus for controlling access 
to services provided by other applications. The method 
makes use of a permit, which includes an access con- 
trol mechanism that resides in a memory space that is so 
protected from a user of the permit The method 
includes receiving a request for a service through a per- 
mit the permit comprising an object defined within an 
object-oriented programming system. In response to 
the request the method activates an access control ss 
mechanism within the permit This access control 
mechanism controls access to the service and resides 
in a memory space that is protected from a user of the 



permit, such that the access control mechanism is trig- 
gered by invoking a method on the permit If the access 
is allowed, the method accesses the service by per- 
forming an invocation on a controlled object This con- 
trolled object includes methods to perform the service, 
and is otherwise protected from the user of the permit. 
Another variation of the above embodiment includes 
receiving, at a permit issuing authority, a request for the 
permit from an entity (such as a person, a computer 
program or a computer process) requiring access to the 
service. If the request includes valid authorization infor- 
mation, a permit is issued to the entity. A further varia- 
tion of the above embodiment includes creating a copy 
of the permit and transferring the copy to an entity 
requiring access to the service. 
[0006] Thus, the present invention provides a method 
for controlling access to a service provided by another 
application. This method does not rely on hardware 
access control mechanisms, and hence can be 
employed by a portable application across a wide range 
of computing platforms. 

BRIEF DESCRIPTION OF THE FIGURES 

[0007] 

FIG. 1A illustrates code modules working together 
within computer system in accordance with an 
embodiment of the present invention. 
FIG. 1B illustrates a number of computer nodes 
coupled together through a network in accordance 
with an embodiment of the present invention. 
FIG. 2 illustrates the process of accessing a service 
in accordance with an embodiment of the present 
invention. 

FIG. 3 illustrates the structure of a permit object 
and a controlled object 320 in accordance with an 
embodiment of the present invention. 
FIG. 4 is a flow chart illustrating the process of cre- 
ating a permit object in accordance with an embod- 
iment of the present invention. 
FIG. 5 is a flow chart illustrating the process of 
using a permit object to access a service in accord- 
ance with an embodiment of the present invention. 

DETAILED DESCRIPTION 

[0008] The following description is presented to ena- 
ble any person skilled in the art to make and use the 
invention, and is provided in the context of a particular 
application and its requirements. Various modifications 
to the disclosed embodiments will be readily apparent to 
those skilled in the ait and the general principles 
defined herein may be applied to other embodiments 
and applications without departing from the spirit and 
scope of the present invention. Thus, the present inven- 
tion is not intended to be limited to the embodiments 
shown, but is to be accorded the widest scope consist- 
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ent with the principles and features cfisclosed herein. 

Distributed Computer System 

[0009] FIG. 1 A illustrates code modules 1 02 and 1 04 
working together within computer system 100 in accord- 
ance with an embodiment of the present invention. In 
order to work with code module 104, code module 102 
requests services from code module 104. Similarly, in 
order to work with code module 102, code module 104 
requests services from code module 102. Access to 
services between modules 102 and 104 is controlled 
through the permit structure described in more detail 
with reference to FIGs. 3-5 below. 
[0010] For purposes of this detailed description, a 
service is a function made available by a first application 
to other applications. This function may provide the 
other applications with access to data or to computa- 
tional resources from the first application. A protected 
memory system is a system that facilitates protection of 
selected regions of memory from an application running 
on the system. 

[0011] FIG. 1B illustrates how the present invention 
can be used in a client-server computer context in which 
a number of computer nodes coupled together through 
a network 1 30 in accordance with an embodiment of the 
present invention. In FIG. 1. servers 110 and 120 are 
coupled to third-party system 140 through network 130. 
Network 130 generally refers to any type of wire or wire- 
less link between computers, including, but not limited 
to. a local area network, a wide area network, or a com- 
bination of networks. In one embodiment of the present 
invention, network 130 includes the Internet Servers 
110 and 120 can be any nodes on a computer network 
including a mechanism for servicing requests from a cli- 
ent for computational or data storage resources. Third- 
party system 140 may be any node a computer network 
communicating with servers 1 1 0 and 120 that is able to 
download code and/or data from servers 110 and 120. 
[0012] In the embodiment illustrated in FIG. 1 , server 
110 contains server code module 1 12, and server 120 
contains client code module 122. Server code module 
1 12 and client code module 122 include modular pieces 
of code that can operate together on third-party system 
140. The dashed lines in FIG. 1 represent server code 
module 112 and client code module 122 being down- 
loaded onto third-party system 1 40 across network 1 30. 
This downloading process can take place in a number 
of ways. In one embodiment of the present invention, 
server 1 10 includes a web site that can be accessed by 
a user on third-party system 140 to download server 
code module 112 onto third-party system 140. Corre- 
spondingly, server 120 includes a web site that can be 
accessed by a user on third-party system 140 to down- 
load client code module 1 22 into third-party system 1 40. 
In another embodiment server code module 112 and 
client code module 1 22 are not downloaded across net- 
work 130. Instead, they are transferred from servers 



1 10 and 120. respectively, to third-party system 1 40 by 
way of computer storage media, such as a computer 
disk 

[001 3] Once server code module 1 1 2 and client code 
5 module 1 22 are located on third-party system 1 40. they 
can be integrated to work together as is illustrated in 
FIG. 1 . For example, in providing a service to client code 
module 122, server code module 112 might retrieve 
data from a database for client code module 122. Atter- 
10 natively, server code module 1 1 2 might perform a com- 
putational operation for client code module 122. This 
integration process may involve determining whether 
client code module 122 has been conferred the right to 
access services from server code module 112. In the 
is reverse direction, this process may involve determining 
whether server code module 112 has been conferred 
the right to access services from client code module 
122. 

so Process of Accessing a Service 

[0014] FIG. 2 illustrates the process of accessing a 
service in accordance with an embodiment of the 
present invention. FIG. 2 illustrates interactions 

25 between server gate 202, system 204 and client code 
module 122 (from FIG. 1). Note that the process for 
accessing a service illustrated in FIG. 2 represents only 
one possible method of obtaining access to a service. In 
general, the present invention applies to any pieces of 

30 code working together in a computer system. Server 
gate 202 is a mechanism that provides permits to prop- 
erty authorized requesters. 

[001 5] For purposes of this detailed description, a per- 
mit is a token held by an entity, which allows the entity to 

35 access a service. In one embodiment of the present 
invention, a permit includes an object defined within an 
object oriented programming system that facilitates 
accesses to a collection of services. 
[0016] Server gate 202 includes an access control 

40 mechanism that controls access to services provided by 
server code module 1 1 2 (from FIG. 1 ). This access con- 
trol mechanism can require varying levels of authentica- 
tion from a requester of a permit. In one embodiment of 
the present invention, server gate 202 is located within 

45 server code module 1 12 on third-party system 140. In 
another embodiment, server gate 202 is located within 
server 1 10 itself, and is accessed via communications 
across network 130. System 204 includes a mechanism 
for establishing that client code module 122 is properly 

so authorized to access services provided by server code 
module 1 12. To this end. system 204 is implemented in 
a number of ways. In one embodiment, system 204 is 
implemented by code that is part of third-party system 
140. In another embodiment, system 204 may be imple- 

55 merited as part of server code module 1 12 within third- 
party system 140. 

[0017] The process illustrated in FIG. 2 operates as 
follows. Client code module 122 is assumed to already 
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exist within third-party system 140. In order to access a 
desired service, client code module 122 requests a 
"ticket" for a "role" to access a collection of services 
from server code module 1 12. A role defines a set of 
operations to be performed by server code module 112. 
Certain roles may be more limited than other roles. For 
example, if serve- code module 1 12 maintains a compu- 
ter f3e system, one role may include only the operation 
of rearing a file from the file system. Another more pow- 
erful role may include the operations of reading, writing 
and deleting files from the file system. 
[0018] In response to the request, system 204 exam- 
ines client code module 122, to determine if client code 
module 1 22 includes proper authorization for the role. In 
one embodiment of the present invention, this examina- 
tion includes examining a certificate chain. This process 
is described in more detail in a co-pending European 
Patent Application No., entitled "Controlling Access to 
Services Between Modular Applications," correspond- 
ing to U.S Patent Application Serial No. 09\ 106. 567., 
which is hereby incorporated by reference in order to 
describe this process. 

[001 9] If client code module 1 22 is properly authorized 
for the role, system 204 issues a ticket for the role, and 
this ticket is given to client code module 1 22. Next, client 
code module 122 passes the ticket to server gate 202. 
Server gate 202 checks the ticket to ensure that the 
ticket is valid. If it is valid, server gate 202 sends a per- 
mit for the service to client code module 122. This per- 
mit allows client code module 122 to access the 
services defined by the role. In one embodiment of the 
present invention, this permit is an object defined within 
an object-oriented programming system. This object 
allows client code module 122 to perform a set of meth- 
ods that comprise the role. After the permit is sent, 
server gate 202 invalidates the ticket so that it cannot 
be used again. Since client code module 122 remains in 
possession of the permit client code module 1 22 will be 
able to access services using the permit, and hence, no 
longer needs the ticket. 

permit PWect 

[0020] FIG. 3 illustrates the structure of a permit 
object 300 and controlled object 320 in accordance with 
an embodiment of the present invention. Permit object 
300 is typically held by a client code module, such as cli- 
ent code module 122 (from FIG. 1). which requires 
access to services provided by a server code module, 
such as server code module 112 (from FIG. 1). Server 
code module 112 maintains controlled object 320, 
which contains code and data used to implement the 
services. Note that the embodiment illustrated in FIG. 3 
is implemented through objects defined within an 
object-oriented programming system. However, the 
invention is not limited to object-oriented programming 
systems. 

[0021 ] Permit object 300 indudes a number of compo- 



nents including controlled object pointer 302, boolean 
vector 304, method -0 pointer 306, method- 1 pointer 
308, method-N pointer 310, permit creation method 
312, permit expiration information 314 and permit log 
5 316. 

[0022] Controlled object pointer 302 points to control- 
led object 320, which is maintained by server code mod- 
ule 1 12, and thereby allows the holder of permit object 
300 to access services associated with controlled 

10 object 320 within server code module 112. Controlled 
object pointer 302 is stored in a memory that area that 
is protected from accesses by client code module 122. 
Client code module 122 cannot directly read or rmxfify 
controlled object pointer 302. Client code module 122 

is cannot access controlled object 320 directly. In order to 
access controlled object 320, client code module 122 
must ask the system to access controlled object 320 
through controlled object pointer 302. Similarly, the 
other data items within permit object 300 are protected 

20 so they cannot be directly read or modified by client 
code module 122. This memory protection ensures that 
client code module 122 must access services associ- 
ated with controlled object 320 by asking the system to 
access the services. This enables the system to restrict 

25 access to the services in a manner that is specified by 
the permit. 

[0023] As mentioned above, this type of memory pro- 
tection can be provided by using the Java™ program- 
ming language and supporting interfaces. The Java™ 

so programming language supports memory protection 
down to the object level. Under the Java model, the only 
way to access data within an object is by invoking meth- 
ods supported by the object Data within an object is 
otherwise protected from memory references - through 

35 a stray pointer for example. Since the Java™ program- 
ming language can be ported across a wide range of 
computing platforms, this object level memory protec- 
tion can be provided across a wide range of computing 
platforms. However, note that it may be possible to get 

40 around the protection mechanism by attacking the inter- 
face between the Java programming language and the 
operating system on a particular computing platform, tn 
order to prevent this type of attack, the Java™ memory 
protection scheme can be extended into the hardware 

45 of a computing platform. 

[0024] Boolean vector 304 contains entries corre- 
sponding to methods provided by controlled object 320. 
These methods implement the services associated con- 
trolled object 320. If an entry includes an "ALLOWED" 

so value, this indicates that the holder of permit object 300 
is allowed to access the corresponding method that 
implements the service from controlled object 320. If the 
entry includes a "NOT ALLOWED" value, this indicates 
the holder of the permit is not allowed to access the cor- 

55 responding method. In this way, permit object 300 spec- 
ifies which services the holder of the permit is allowed to 
access. Since boolean vector 304 is located in pro- 
tected memory, a holder of permit object 300 cannot 
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modify boolean vector 304 to gain unauthorized access 
to a service. Note that there are many possible ways to 
indicate that particular methods are not allowed. In 
another embodiment methods within permit object 300 
are coded to call a corresponding method in controlled s 
object 320. Otherwise, they are coded to indicate that 
the method is not allowed. 

[0025] The methods specified in controlled object 320 
are accessible through method pointers within permit 
object 300. These method pointers include method-0 u 
pointer 306, method-1 pointer 308 and method-N 
pointer 3 1 0. Client code module 1 22 must access meth- 
ods 324, 326 and 328 through these method pointers 
306. 308 and 310. Method-0 pointer 306 points to 
method-0 324 within controlled object 320. Method-1 is 
pointer 308 points to method-1 326 within controlled 
object 320. Method-N pointer 310 points to method-N 
328 within controlled object 320. These method pointers 
reside in protected memory so that client code module 
1 22 must access the methods through the system. 20 
[0026] In the illustrated embodiment, permit object 
300 additionally includes permit creation method 312, 
which allows a holder of permit object 300 to create a 
copy of permit object 300, and to transfer the copy to 
another application. This allows client code module 1 22 2s 
to farm out a sub-task requiring services from controlled 
object 320 to another module. Note that permit creation 
method 312 allows only less powerful copies of permit 
object 300 to be made. In other words, copies of permit 
object 300 can access at most the same methods from 30 
controlled object 320, and possibly fewer methods. 
[0027] Permit object 300 additionally includes permit 
expiration information, which specifies some type of 
lifespan limitation for the permit. In one embodiment 
this is accomplished by specifying a certain time period 3s 
during which the permit is valid. In another embodiment 
this is accomplished by requiring that the system first 
check in a central database to see that the permit 
remains still valid. 

[0028] Permit object 300 also includes permit log 316, 40 
which records a log of access requests to permit 300. 
This log can be used for security purposes to monitor 
how permit object 300 is being used. Alternatively, a log 
of access requests can be maintained within controlled 
object 320. 4s 
[0029] Controlled object 320 contains data 322. which 
is used by methods 324. 326 and 328 to implement 
services associated with controlled object 320. For 
example, data 322 may contain file system data and 
methods 324. 326 and 328 may specify file system so 
operations. 

Permit Creation 

[0030] FIG. 4 is a flow chart illustrating the process of ss 
creating a permit object in accordance with an embodi- 
ment of the present invention. This flow chart describes 
in more detail the operations performed by server gate 



202. which were described previously with reference to 
FK3. 2 above. The system starts at state 400 and pro- 
ceeds to state 402. In state 402. client code module 1 22 
performs an invocation on server gate 202 to make a 
new permit As mentioned above, this invocation 
includes a ticket for a role as a parameter. The system 
then proceeds to state 404. In state 404, server gate 
202 authenticates the ticket, and if it is valid, server gate 
202 makes a new permit object 300. This process may 
include locating a controlled object 320 to associate 
with permit object 300, or if necessary, making a new 
controlled object 320 within server code module 112. 
The system next proceeds to state 408. In state .408, 
controlled object pointer 302 (from FIG. 3) is assigned 
to point to controlled object 320. The system next pro- 
ceeds to state 410. In state 410, the system sets access 
control flags (entries in boolean vector 304) to specify 
which methods the holder of the permit is allowed to 
invoke. The system next proceeds to state 410. In state 
410, permit object 300 is returned to client code module 
122. The system next proceeds to state 414, which is an 
end state. 

Use of Permit Object 

[0031 ] FIQ. 5 is a flow chart illustrating the process of 
using a permit object to access a service in accordance 
with an embodiment of the present invention. The sys- 
tem starts at state 500 and proceeds to state 502. In 
state 502, client code module 122 (from FIG. 1) invokes 
a method on permit object 300 (from FIQ. 3). The sys- 
tem proceeds to state 504. In state 504. the system 
checks access control flags corresponding to the 
method. This entails looking up an entry in boolean vec- 
tor 304 corresponding to the invoked method. If this 
access control flag indicates the method is allowed, the 
system proceeds to state 506. Otherwise, the system 
proceeds to state 51 0. 

[0032] In state 506 the access is allowed, so the sys- 
tem invokes the appropriate method on permit object 
300, which causes a corresponding method to be 
invoked on controlled object 320 with the appropriate 
parameters. The system next proceeds to state 508, In 
state 508, the system waits for the invocation to com- 
plete, and then returns a result to client code module 
1 22. The system next proceeds to state 512, which is an 
end state. 

[0033] In state 510, the method is not allowed. In this 
case, the system indicates to client code module 122 
that the method is not allowed. This can be done in a 
number of ways. In one embodiment of the present 
invention, the system causes an exception to occur in 
the execution stream of a processor performing the 
method invocation. In another embodiment the system 
sets a global variable to indicate that the attempted use 
of permit object 300 failed. In yet another embodiment, 
the invocation to permit object 300 returns a NULL 
valua The above process is repeated for successive 
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invocations on permit object 300. 
[0034] The foregoing descriptions of embodiments of 
the invention have been presented tor purposes of illus- 
tration and description only. They are not intended to be 
exhaustive or to limit the invention to the forms dis- s 
closed. Accordingly, many modifications and variations 
win be apparent to practitioners skilled in the art 

Claims 

1 . A method for controlling access to services in a pro- 
tected memory system, comprising: 

receiving a request for a service through a per- 
mit, the permit comprising an object (300) 15 
defined within an object-oriented programming 
system: 

in response to the request, activating an 
access control mechanism (500) within the per- 
mit the access control mechanism controlling 20 
access to the service and residing in a memory 
space that is protected from a user of the per- 
mit, such that the access control mechanism is 
triggered by invoking (502) a method (306-31 0) 
on the permit; and 2s 
if the access is allowed, accessing the service 

2. The method of claim 1, wherein the access control 
mechanism (500) provides access to the service by 
performing an invocation (506) on a controlled 30 
object (320), the controlled object including a 
method (324-328) to perform the service, and oth- 
erwise being protected from the user of the permit 

3. The method of claim 1 or claim 2, further compris- 35 
ing if the access is not allowed, indicating (510) to 

an entity requesting the service that the access to 
the service is not allowed. 

4. The method of claim 1 or claim 2, wherein the per- 40 
mit (300) is defined within the Java™ programming 
language and supporting interfaces. 

5. The method of any one of claims 1 to 4, wherein 
data (322) protected by the permit (300) can only 45 
be accessed through methods (306-310) invoked 

on the permit. 

6. The method of any one of claims 1 to 5, further 
comprising: so 

receiving, at a permit issuing authority, a 
request for the permit from an entity requiring 
access to the service: and 

if the request includes valid authorisation infor- ss 
mation, issuing the permit (412) to the entity. 

7. The method of any one of claims 1 to 6, further 



10 

comprising creating a copy of the permit (300) and 
transferring the copy to an entity requiring access to 
the service. 

8. The method of claim 7, wherein the copy of the per- 
mit allows access to fewer services than the permit 
(300) that it was copied from. 

9. The method of any one of claims 1 to 8, further 
comprising determining whether the permit has 
been revoked before accessing the service, and 
been revoked, indicating (510) the access is not 
allowed. 

10. The method of any one of claims 1 to 9, further 
comprising recording the access request in a log 
(31 6) associated with the permit 

11. The method of any one of claims 1 to 10. wherein 
activating the access control mechanism includes 
determining (314) whether the permit has expired. 

12. The method of any one of claims 1 to 11, wherein 
the access control mechanism includes a pointer 
(302) to the controlled object (320). the pointer 
residing in the memory space that is protected from 
the user of the permit. 

13. The method of any one of claims 1 to 12, wherein 
the access control mechanism includes a method 
(324-328) to be invoked to perform the service, 
wherein if access is not allowed, the method (324- 
328) does not perform the service, but instead indi- 
cates (510) that access to the service is not 
allowed. 

14. The method of any one of claims 1 to 13, wherein 
the access control mechanism includes a variable 
(304) associated with a method to be invoked to 
perform the service, wherein the variable indicates 
whether the access is allowed. 

15. A computer readable storage medium storing 
instructions that when executed by a computer 
cause the computer to perform a method for con- 
trolling access to services in a protected memory 
system, comprising: 

receiving a request for a service through a per- 
mit the permit comprising an object (300) 
defined within an object-oriented programming 
system; 

in response to the request activating an 
access control mechanism (500) within the per- 
mit the access control mechanism controlling 
access to the service and residing in a memory 
space that is protected from a user of the per- 
mit such that the access control mechanism is 
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triggered by invoking (502) a method (306*310) 
on the permit; and 

if the access is allowed, accessing the service 
by performing an invocation (506) on a control- 
led object (320), the controlled object including s 
a method (324-328) to perform the service, and 
otherwise being protected from the user of the 
permit 

16. An apparatus for controlling access to services in a w 
protected memory system, comprising: 

a permit means through which a user can 
access a service, the permit means optionally 
comprising an object (300) defined within an is 
object-oriented programming system; 
an access control means (500) within the per- 
mit the access control means controlling 
access to the service and residing in a memory 
space that is protected from a user of the per- 20 
mrt such that the access control means is trig- 
gered by invoking (502) a method (306-310) on 
the permit; and 

a request processing means, in communication 
with the permit means, that is configured to 2s 
receive an access request for the service 
through the permit means, and to activate the 
access control means. 

1 7. The apparatus of claim 1 6, wherein the access con- 30 
trol means (500) is configured to provide access to 
the service by performing an invocation (506) on a 
controlled object (320), the controlled object includ- 
ing a method (324-328) to perform the service, and 
otherwise being protected from the user of the per- 35 
mit(300). 

18. The apparatus of claim 16 or claim 1 7, wherein the 
request processing means is configured to indicate 

(51 0) that the access to the service is not allowed if 40 
the request processing means determines that the 
access is not allowed. 

19. The apparatus of any one of claims 16 to 18. 
wherein the access control means (500) includes at 45 
least one method (324-328) to be invoked to per- 
form the service. 

20. The apparatus of any one of claims 16 to 19. 
wherein the permit (300) is defined within the so 
Java™ programming language and supporting 
interfaces. 

21. The apparatus of any one of claims 16 to 20, 
wherein data (322) protected by the permit (300) ss 
can only be accessed through methods (306-310) 
invoked on the permit 



22. The apparatus of any one of claims 16 to 21, further 
comprising a permit creation mechanism (400) that 
receives a request for the permit (300) from an 
entity requiring access the service, and if the 
request includes valid authorisation information, 
issues (412) the permit to the entity. 

2a The apparatus of any one of claims 16 to 22, further 
comprising a permit copying mechanism that is 
configured to create a copy of the permit (300) and 
to transfer the copy of the permit to an entity requir- 
ing access to the service. 

24* The apparatus of any one of claims 16 to 23, 
wherein the permit copying mechanism is config- 
ured to produce the copy of the permit that allows 
access to fewer services than the permit (300) it 
was copied from. 

25. The apparatus of any one of claims 16 to 24, 
wherein the request processing means is config- 
ured to determine (504) whether the permit has 
been revoked before accessing the service. 

26. The apparatus of any one of claims 1 6 to 25, further 
comprising a log (316). associated with the permit, 
to record access requests. 

27. The apparatus of any one of claims 16 to 26, 
wherein the request processing means is config- 
ured to determine (314) whether the permit has 
expired. 

2a A data structure contained in a computer readable 
storage medium for controlling access to services 
in a protected memory system, the data structure 
comprising: 

an access control mechanism (500) within the 
data structure, the access control mechanism 
controlling access to the service and residing in 
a memory space that is protected from a user 
of a permit (300), such that the access control 
mechanism is triggered by invoking (502) a 
method (306-310) on the permit; and 
an access control indicator (304) within the 
data structure, the access control indicator 
specifying services the user can access, the 
access control indicator being protected from 
rnodrf ication by the user. 

29. The data structure of claim 28, wherein the access 
control mechanism (500) includes a pointer to 
code(324-328) that implements the service, the 
pointer residing in the memory space that is pro- 
tected from the user. 

30. The data structure of claim 28 or claim 29, wherein 
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the access control indicator (304) includes a varia- 
ble associated with a service, wherein the variable 
indicates whether access to a corresponding serv- 
ice is allowed. 

31. A computer program or applet encoding a set of 
computer instructions for controlling access to serv- 
ices in a protected memory system, which when 
running on a computer is adapted to perform the 
method of any one of claims 1 to 14. 
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